Show code cell source
import os
# Por precaución, cambiamos el directorio activo de Python a aquel que contenga este notebook
if "PAD-book" in os.listdir():
os.chdir(r"PAD-book/Laboratorio-Computacional-de-Analytics/S1 - Bienvenida, estructuras de datos y de control/S1.LE1/")
¿Qué papel juega la programación en analítica de datos?#
El primer gran mensaje de este curso es que la programación es ineludible. Incluso fuera del área de ciencia, tecnología o ingeniería, se habla cada vez más de code literacy, o la idea de que tener un entendimiento básico de las tecnologías relacionadas con algoritmos y programación serán tan importantes como la lecto-escritura y las matemáticas básicas. Para el caso de la analítica, esto es aún más relevante, pues queremos trabajar directamente con manipulación de datos y algoritmos.
Esta lectura desarrolla tres ideas al respecto:
por qué la programación es ineludible en el mundo actual,
cómo entender la programación más allá del código,
qué relación tiene la programación con los diferentes perfiles de la analítica de datos.
Por qué la programación es ineludible en el mundo actual#
La respuesta corta es que dependemos cada vez más de las máquinas (ej., Smart-Grid, vehículos autónomos, Industria 5.0, etc.) y la programación es un lenguaje para comunicarnos con ellas.
En general, los datos que nos interesa analizar son numerosos y los métodos que utilizamos para analizarlos implican operaciones repetitivas, a veces complejas, sobre ellos. Por esto, buena parte de lo que se hace en análisis de datos es hecho por un computador, desde la aplicación de procedimientos para preparar los datos hasta entrenar modelos sofisticados para analizarlos. Existen librerías especializadas que nos ayudan a llevar a cabo estas tareas, pero se requiere un nivel de programación o scripting básico para poner esas funcionalidades al servicio de un proyecto de analítica de datos para responder a una necesidad de una organización. Esta tarea de integrar procesos técnicos de forma coherente con el problema que se busca resolver es una parte crucial del quehacer de un profesional en analítica de datos (como veremos en la siguente sección), y constituye una ventaja competitiva profesional, porque quien lo hace es quien tiene la visión panorámica del proyecto.
Una concepción errada sobre la programación es que se trata de memorizar comandos, lo cual puede ser una receta segura para que su aprendizaje sea tedioso. Es más interesante pensar en la programación como el proceso de entender un problema y reducirlo a una serie de pasos lógicos que podemos “delegar” a una máquina. Para esto, utilizamos lenguajes muy simplificados respecto a los que hablamos las personas, porque interesa que sean fáciles de aprender y usar de manera general. Así, podemos combinar el tipo de inteligencia que tenemos los humanos (esa que es compleja, desestructurada y nos hace creativos para resolver problemas) con la inteligencia operativa de los computadores, que es rápida y precisa para procesos complejos y repetitivos. La programación nos permite agregarle un enorme poder de cómputo a nuestras mejores estrategias para resolver problemas.
El reto del analista está en lograr traducir las problemáticas del negocio a tareas que un computador pueda ejecutar y, por supuesto, traducir las soluciones obtenidas de vuelta al contexto del negocio. La siguiente figura sintetiza este proceso, en el cual el bloque de la mitad implica justamente orquestar una serie de tareas técnicas que discutiremos más adelante. De los cuatro retos que se enuncian en la parte inferior, el segundo y el tercero son los más directamente relacionados con tareas técnicas de programación (preparación de datos, evaluación de modelos) en el marco de un proyecto de analítica de datos.
En consecuencia, la programación es el medio para poner la computación al servicio de la toma de decisiones. Requiere que aprendamos a expresar nuestras ideas en un lenguaje simple. “Si no puedes explicarle al computador lo que tienes en mente, tal vez no lo tienes tan claro” es una frase popular entre programadores, similar a la del físico Richard Feynman: “si no se lo puedes explicar a un niño, realmente no lo entiendes”. La siguiente sección enfatiza que un buen programador resuelve el problema antes de escribir la primera línea de código: un buen esquema gráfico del problema o un buen diagrama de flujo pueden ahorrar horas y hasta días de frustración con un problema de programación.
Cómo entender la programación más allá del código#
En un proyecto de analítica de datos, así como en cualquier otro proyecto, conceptualizar el problema y plantear un esquema general de solución son pasos indispensables antes de empezar a programar.
Un buen programador está haciendo su trabajo mucho antes de empezar a escribir código. Sentarse a escribir código sin tener clara la lógica de lo que se busca resolver es una receta para los tropiezos y la frustración. Por eso, cuando hablamos de programación, se puede pensar en tres niveles que responden al proceso completo de solucionar un problema: desde concebir una estrategia general con la cual abordar el problema, pasando por convertirla en un proceso lógico, y finalmente llevando ese proceso lógico al código.
El primer nivel tiene que ver con estructurar el problema, aún lejos de pensar en computadores. Se trata de entender el estado actual de un sistema o problema, identificar un estado deseado y una forma de llegar a él con base en la información y recursos disponibles. Incluso, es útil preguntar por qué la situación actual es un problema, pues tal vez exista una respuesta que conduzca a una solución no relacionada con programación. Esto no es trivial, pero contribuye a tener clara la lógica del problema de forma que se pueda proceder a programarlo.
El segundo nivel es lo más cercano a la palabra programar: se trata de establecer un proceso y unos flujos de información que, puestos en pasos lógicos, permitan resolver el problema. Este es el núcleo principal en la solución del problema y no necesariamente requiere ser expresado en sintaxis de ningún lenguaje de programación. Basta con un pseudo-algoritmo o diagrama de flujo escrito en papel con los pasos para resolver el problema, cuya implementación en código puede incluso sub-contratarse, si es el caso.
El último nivel es justamente codificar; algo más cercano al estereotipo de escribir palabras especiales de colores en una pantalla negra. Es un paso muy importante porque su implementación determina características fundamentales de la solución, por ejemplo: si el programa es eficiente, escalable, seguro, entre otras, pues un mismo programa (i.e., un mismo diagrama de flujo) admite diferentes implementaciones en código. Es importante entender las implicaciones de la implementación en código, pero no son el foco principal del trabajo en análisis de datos.
Pensar la programación en esos tres niveles es importante, porque una conceptualización errada del problema seguramente va a hacer que la implementación del código sea ineficiente y frustrante. Usando un juego de palabras que funciona bien en inglés: en el nivel superior nos preocupamos por estar doing the right thing (hacer aquello que es correcto hacer) mientras que en el inferior nos aseguramos de estar doing the thing right (hacer la cosa correctamente). Resolver problemas en el contexto de análisis de datos va desde una visión estratégica y de alto nivel organizacional, hasta la definición de instrucciones precisas que pueda seguir una máquina. El reto del programador es justamente conectar ambos mundos: traducir una necesidad de negocio en especificaciones técnicas de lo que debe hacer un programa computacional.
Qué relación tiene la programación con los diferentes perfiles de la analítica de datos#
Ya sabemos que la programación es ineludible y que conceptualizar previamente la solución nos ayuda a expresar a un computador nuestras ideas para resolver un problema, incrementando enormemente nuestra capacidad de análisis para la toma de decisiones. Sin embargo, no todos buscan relacionarse con la programación al mismo nivel. Esta sección discute cómo se aborda la programación desde diferentes roles en análisis de datos. ¿Qué tanta programación necesito para desenvolverme en el contexto de análisis de datos según mi perfil?
A nivel gerencial, la respuesta corta es: no tanta como la que requiere un desarrollador o analista (porque seguramente habrá alguien especializado en tu equipo), ni tan poca que no puedas comunicarte y liderar equipos involucrados en implementaciones computacionales.
A nivel de analista, la respuesta varía un poco: no necesitas tanta programación como quienes desarrollan las librerías, algoritmos y plataformas especializadas, pero sí se requiere un nivel de scripting y un dominio considerable de los paquetes apropiados, porque la labor del analista es altamente exploratoria. Las ideas de soluciones por lo general vienen de manipular los datos, mezclarlos, reorganizarlos, visualizarlos, intentar diferentes modelos sobre ellos. No podrás hacer análisis autónomamente si necesitas a alguien más para esto, pues sería como tratar de cocinar y que sea otra persona la que va probando la sazón.
Por último, la programación fuerte, esa que está debajo del capó, solo se necesita si se quiere desarrollar o especializar métodos de solución, ya sea en investigación o como parte de un equipo de soporte de software o infraestructura. Parafraseando una analogía que usa la jefe de Decision Intelligence de Google, Cassie Kozyrkov: “así como podemos usar un horno microondas, aunque no lo sepamos diseñar, podemos resolver problemas de análisis de datos sin que sepamos implementar los métodos desde cero; basta con saberlos usar bien. Otro asunto sería dedicarse a diseñar hornos microondas, en cuyo caso sí sería indispensable una habilidad técnica profunda”.
En síntesis, no todo aquel que trabaje en el área de Analytics debe dedicarse en profundidad a cada aspecto (modelamiento matemático, gestión de negocio, tecnologías de información), pero un buen analista (un experto) debe entender estas subáreas y sus interrelaciones con el propósito de comunicarse efectivamente con quien se desempeña en cada una de ellas e incluso liderar equipos. Por ejemplo, un gerente que no entiende la diferencia entre modelos predictivos y prescriptivos puede ser tan nocivo como una persona técnica que no diferencia rentabilidad y utilidad. Entender el rol del otro ayuda al equipo.
Créditos#
Autores: Camilo Hernando Gómez Castro, Alejandro Mantilla Redondo, Diego Alejandro Cely Gómez
Fecha última actualización: 07/07/2022